| Academic Open Internet Journal ISSN 1311-4360 |
Volume 21, 2007 |
WebATU: Web Service Automated
Testing Utility
Deena Yunam , N.Ch.S.N.Iyengar & A.Kannammal*
Vellore-632014
T.N,
*Department
of Computer Technology& Applications
Coimbatore
Institute of Technology
Coimbatore-641014,
Tamilnadu
Abstract
Web Services is arguably the most powerful and popular software
technology in today’s connected e-world. This paper gives a briefing about web
services and also touches upon the various standards that have evolved over the
years, such as XML, SOAP, WSDL, and UDDI. This paper advocates the need for
testing web services as Testing Web Services poses a big challenge to testing professionals
because of its inherently complex and distributed nature. Web Service Automated Testing Utility
(WebATU) will enable us to locate and invoke web service methods directly. It
supports all of the core Web service technologies like WDSL, SOAP, and it is an
ideal Web service tool for testing Web services, inspecting WSDL files,
automating or accelerating verification of each component when developing Web
service enabled applications.
Keywords: web service,
WSDL, SOAP, Axis, functional testing.
1. Introduction
As we move towards a more connected
world, the web is becoming an integral part of our lives. With the invention of
Web Services, distributed computing is once again gaining focus of many leading
organizations and industry experts. Web Services as the name implies, offer
services over web for consumers, and it is set to play a very important role in
the future of computing.
1.1 Web
Services
The layman’s definition for Web Services
can be, an application that provides a Web API. A web
API is an API which provides communication using Extensible Markup Language (XML)
and the web. Web services are arguably the most powerful and popular software
technology in today’s connected software world.
Web Services promise Internet enabled
modular, standards based, platform independent and language neutral method for
integrating applications on the web. Web Services are a new form of middleware
based on XML and the Web. Traditional middleware technologies have numerous
limitations/drawbacks: Usage difficulty, Lack of heterogeneity, Expensive, Maintenance
difficulty, Tight coupling with the solutions they work for, Platform dependence
at lower layers, Lack of Support for complex distributed systems, etc.
Web Services can solve the issues
mentioned above as they are platform and language independent. Web Service developed
in one language can be deployed on any platform. In addition, once a Web
Service is deployed, it can be accessed by any other application, regardless of
language or platform. This is primarily achieved by XML and Web protocols which
are platform and language independent and can work both internally and across
the Internet.
As stated earlier, traditional middleware
such as RPC, CORBA and DCOM are tightly coupled with the solutions due to which,
they can create problems when modifications are made to the solutions. On the
other hand, Web Services are loosely coupled with the solutions, hence reducing
the impact of changes in the solutions. In addition, Web Services have evolved
over the years based on industry standards like XML, SOAP, WSDL
and so on. This has obviously made Web Services gain more acceptance than the previous
middleware technologies.
1.1 Web Services Standards
Although Web Services can be considered
an independent architecture, it has its basis on a set of standards. Prominent
industry leaders are working on the set of standards that enable the web
services architecture to be scalable and interoperable. Apart from the most
poulary used XML, the web services standards that have evolved over the last
few years is given an overview.
1.1.1
WSDL (Web Service Description Language)
The W3C defines WSDL as an XML format for
describing network services as a set of end points operating on messaging
containing either document-oriented or procedure-oriented information. The
operations and messages are described abstractly, and then bound to a concrete
network protocol and message format to define an endpoint. WSDL basically
provides a universal interface for consumers. It plays an important role for
the consumer since the consumer is not exposed to any other details apart from
WSDL for utilizing the web services.
1.1.2
SOAP (Simple Object Access Protocol)
SOAP is a light weight protocol for
exchanging information in a distributed environment. It provides a simple
mechanism for exchanging information between peers using XML. As such SOAP does
not define programming model or implementation details. It just defines a
simple mechanism for expressing application semantics.
1.1.3
UDDI (Universal Discovery, Description and Integration Language)
The Universal Discovery, Description and
Integration protocol is one of the important standards from the Web Services
stack. The UDDI specification defines a standard method for publishing and
discovering the network based software components of a web service.
1.3.5
Axis
Axis is the third generation of
Apache SOAP, essentially a SOAP engine—a framework for constructing SOAP
processors such as clients, servers and gateways. It delivers the key features
like speed, flexibility, stability and transport framework. Axis supports the
Web Service Description Language, version 1.1 which allows build stubs easily, to
access remote services, and also to automatically export machine - readable
description of deployed services from Axis.
1.2 SOA (Service-Oriented Architecture)
Service-Oriented
Architecture is essentially a collection of services. These services
communicate with each other that can data processing or coordination of
activities. SOA has been present since
the days of DCOM and CORBA. Essentially
it is an architectural style whose goal is to achieve loose coupling among
interacting software components.
Figure 1 illustrates
service oriented architecture in its simplest form. The communication is
typically carried out in a manner which is understandable to both the consumer
and the provider.
Web Services technology can be
stated as an instantiation of this design pattern known as Service-Oriented Architecture,
which has been used traditionally to design and build distributed systems.
2.
MOTIVATING APPLICATION
The application provided in this paper is
the WEBATU:Web Service Automated Testing Utility. WebATU supports deep testing of
Service – Oriented Architectures (SOA) consisting of any number of web
services, which are tied to back-end databases.
- No-code
SOAP/XML testing and WSDL exploration and test maintenance. All the
information need to know is the URL to capture and invoke any type of test
against a web service.
- WebATU
is no-code automated testing, meaning no longer have to script tests.
- WebATU
runs on any client and supports Java and .NET and any other SOAP compliant
web service.
WebATU provide the way to perform
several tests in very short period of time. It supports Functional Testing
to ensure that the functionality of the web service is as expected. It allows to run all test cases one time for each web service. Figure
2 depicts the architecture of the proposed system.
Figure 2 – System Architecture
WebATU
gives request to web server for WSDL through client browser, server gives WSDL
file as response to client browser, and the tool fetch the wsdl from browser.
With the help of Apache Axis client, WebATU generates all the required stubs to
invoke and execute the available API’s in the web services. WebATU communicates
with server through SOAP messages which makes WebATU to be x language and platform
independent.
3. DESIGN
OF PROPOSED APPROACH
3.1
Use Case Modeling
The functional requirements of the system are specified in terms of
use cases. A use case is a scenario describing the interaction between the user
and the system. The use case modeling for the proposed architecture is depicted
in Figure 3.
Figure
3 Use Case Modeling
The actor can be
a developer, a Qaulity Assurance or Testing person. The description of use
cases follows:
- Retrieve WSDL from web
application: retrieves the WSDL from the
deployed web service application.
- Execute Axis WSDL tool command: generates the stubs using Axis WSDL2Java tool. where
stub is a client side program which acts as a proxy for the server. Stubs
are used to make calls to the webservices .
- Create
testclient: it imake
use of stub and will help in invoking services of web service.
- Invoke
services: the
services available in web services application are invoked to perforn
functional testing.
- Verify
output: functional
testing is performed.
3.2 Collaboration Modeling
The
collaboration between various components is given by Figure 4.
Figure 4 Collaboration Modeling
The testclient would call the stub and make use of all the classes available
inside the stub for testing web service. Some of the classes present inside
stub are:
- Service.java: service interface of
the webservice. The service locator implements this interface.
- ServiceLocator.java: helper
factory to retrieve a handle to the service.
- SoapBindingStub.java: client side
stub that encapsulates the client access.
- Exception.java: Serialized beans
generated dynamically and used as input and return in addition to catching
the exceptions.
4 IMPLEMENTATION
WebATU can
be implemented in wide area of testing in any kind of web application software
in todays IT industry. According to the architecture of the web application, a
user has to configure and setup the application to be ready to communicate with
any compliance clients. The setup may require configuring Apache Tomcat server
according to the architecture. The proposed system
can be broadly divided into two modules namely server setup and client setup.
4.1 Server Setup
In order for a Web Service to be accessible by Axis compatible clients,
the Service must first be deployed, and desired methods enabled. Deployment can
be done dynamically while the server is started. The user can do this either by
accessing the administrative web page of the Axis server runtime through a web
browser, or by remotely invoking proper methods of the Axis server runtime
through an Axis compatible client.
4.2 Client Setup
Once the server is up and running, any Axis compliant client can
begin invoking methods of deployed services after proper authentication. Since the underlying transport protocol can
be HTTP or NON HTTP, authentication is currently implemented using a common login web service. This web service
returns a sessionID, which the client uses for calls to the rest of the web services.
After a connection is established, clients call the services by providing the
method name and its corresponding parameters. The sub modules of Client Setup
are detailed in the following sections.
4.2.1 Obtain WSDL for deployed services
When a service is made available through Axis,
there is typically a unique URL associated with that service. If the service is accessed through that URL
in a browser, a message can be seen, indicating that the endpoint is an Axis
service that should be usually accessed using SOAP. However, if we tack on
"?wsdl" to the end of the URL, Axis will
automatically generate a service description for the deployed service and
return it as XML in the browser. The
resulting description may be saved or used as input to proxy-generation.
http://localhost:8080/axis/<service-name.wsdl>
4.2.2 Generate Stubs/Drivers
The required steps to generate Stubs or
Driver are
1.
Extract the WSDL for the
required webservices.
2.
Use the WSDL2Java Axis utility
to generate the Axis stubs specific to Java.
3.
Use the stubs to make calls to
the webservices.
For example: WebService :
Calculator API
URN : http://localhost:8080/axis/CAlculatorAPI.jws
Method : subtract
Input Params: int
a1, int a2
Output Params:
a1-a2
Step1: extract
the WSDL for the webservice
Enter http://localhost:8080/axis/CalculatorAPI?wsdl
in the browser to obtain the WSDL for the webservice.
Step2: use Axis
WSDL2Java tool for generating the stubs
On the command
prompt type: “Java org.apache.axis.wsdl.WSDL2Java –o .
–ptesting.soap AccountService.wsdl”. This generates
the following files in the package testing\soap.
- AccountService.java: New interface
file that contains the appropriate java.rmi.Remote usages.
- AccountServiceService.java:
service interface of the webservice. The service locator implements this
interface.
- AccountServiceServiceLocator.java:
helper factory to retrieve a handle to the service. 4)AccountServiceSoapBindingStub.java:
client side stub that encapsulates the client access.
- Account,User,*Exception.java:
Serialized beans generated dynamically and used as input and return in
addition to catching the exceptions.
Step3: Using the
Stub to make calls to the web services.
Verify the bean
classes before using them as input and output parameters.
4.2.3
Invoke Services
Using
the generated stubs and drivers, all the available services should be able to get
invoked using java client program which could be deployed into the web server.
This WebATU would provide a user friendly GUI to invoke all these services.
4.2.4 Testing Strategy: Functional Testing
This type of testing is done to ensure that the functionality
of the web service is as expected. Functional testing also takes care of bounds
testing and error checking. Essentially, functional testing is carried out to
test the behavior of the system as a whole. When performing functional testing
for Web Services, it becomes important that all the methods exposed by a WSDL
are tested properly with proper input values. Ideally, the functional testing
tool should fit into the framework as depicted in Figure 5.
A STUB generator is a program which reads the WSDL file and
gives the tester all the exposed methods by the web service. The WSDL file also
contains other vital information about the exposed methods, like the input
parameters and output parameters. It also contains information about complex
data types if they are required for some methods. While testing Web Services,
it becomes necessary to have a STUB generator which provides the necessary SOAP
stubs for calling the exposed methods in WSDL. Once the SOAP stubs are created,
the next big task is to create the input parameters for a method under test.
The popular tool Axis is used widely to generate SOAP stubs
from the WSDL specifications. It generates code after reading the WSDL file.
Once the code is generated it is normally consumed by a client code which is
language specific to get the functional testing done.
5
RESULTS
SCREEN
SHOTS
Screen
1
This is an input screen used for entering the WSDL
file.
Screen
2
This form will give all the methods present in the WSDL file. When
you select any method present in the combo box, the return type of the method,
no of parameter as well as its type will be visible in the text area.
Screen 3
This form is
used for how u prefer to give inputs of the parameter present in the method u
have already selected.
Screen 4
This is the
output screen. It shows the result of the testing process you have done. If the
testing is successful it’ll print “finish safely” otherwise it’ll print all the
exception being encountered
6 CONCLUSION
Due to its inherent complex nature, testing Web Services
poses various challenges to test
engineers. WebATU is developed after thorough study of
Web Service Architecture and its related technologies. It is an excellent web service
Functional Testing Tool. WebATU is very fast and execute with great
speed because it uses Sax Parsing. WebATU
runs on any client and supports Java and .NET and any other SOAP complaint web
service.
7 FUTURE WORK
The current features provide to amend the basic needs of tester and
a programmer to test and verify functionalities of each API in the web service,
irrespective of the platform and languages used in the development. However,
elaborate results and reports on each API could be generated with enhancement
of the current tool by embedding new features in the future. For example a new
feature can be added as an enhancement that would generate report on each API
after the completion of test execution, by which all the users can view the
report on his/ her mail box. Also another feature can be added, which enables a
user to run the test suit online, which will be more efficient and effective in
the product testing life cycle. To eliminate the complexity associated with the
changes that takes place in the WSDL, the location of the WSDL file can be referred
to instead of saving the WSDL file in the local disk.
8 REFERENCES
- Elfriede Dustin. Effective software Testing-50 specific
ways to improve your testing
- William E.Perry. Effective Methods For Software Testing
- Bosworth Adam;Developing Web Services;IEEE,2001
- Curbera Francisco, Duftler Mathew,
Khalaf Rania, Nagy William, Mukhi Nirmal,Weerawarana Sanjiva; Unravelling the Web Services:Web-An
Introduction to SOAP,WSDL and UDDI;
- IEEE Internet
Computing,March/April 2002
- Web Services Architecture, February
2004,www.w3.org/TR/ws-arch/
- Web Services Description Language,
August 2005,http://www.w3.org/TR/wsdl20/
- SOAP Version 1.2 Part 0: Primer, June 2003,
- http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
- Jeffery
Buzen, Leo Parker, “Measurement Principles for Web Services”,December 2003
- Mike
Vermeulen, “Testing Web Services”, August 2002
Technical College - Bourgas,
All rights reserved, © March, 2000
